When storing files on a storage medium, usually an address space is defined in the storage medium. The files are not always stored as a whole. Rather, they are divided into different packets. Then, it has to be registered where the different portions of the file are stored. To this end, a so-called file allocation table also denoted as FAT is defined. If the address space is defined with respect to units of constant size, the file allocation table usually comprises one entry per such unit. If a packet of the file is stored under an address, there is a respective entry in the file allocation table for that address. In that entry, another address is written. This other address is the address of the location in the address space where the next portion of the file can be found. Therefore, when jumping from one address to the next, the file can be successively retrieved. The file allocation table defines the way the reading head or other transducer accessing the storage medium must go. The smaller the different packets of the file are, the more often the head must jump, causing idle time not usable for data transfer and lowering the average transfer bitrate. Notably, idle times occur upon head jumps both when writing these files and when reading these files. In a video recording apparatus, it is essential that writing as well as reading of files be performed in real time. Every jump the write/read head of the storage medium has to do means a loss in bandwidth. It is therefore desirable that in video recording apparatus the streaming data be stored in large packets. If too small data packets are used, the longer files occupy a multiplicity of small data packets. There is not always a single, contiguous storage place for the whole multiplicity. This means that the data have to be divided and the space will be fragmented.
On the other side, storing data in large packets means a high degree of so-called internal fragmentation, since small files and directories, although physically requiring only a small fraction of a packet, will nevertheless block the entire large packet. Traditional file systems overcome the conflicting requirements of high bandwidth versus low internal fragmentation by using a small packet size but allowing the allocation of so-called extents, that is, a multiplicity of contiguously arranged small data packets. One problem with extents is that frequent allocation and freeing of differently sized data packets, be it single packets or extents, leads to scattered occupancy of available address space. Thus, a situation can occur where the file system doesn't allow further allocation of extents, though there's still enough free space on the partition. This is called external fragmentation. External fragmentation may be overcome by a defragmentation step, which is however time consuming.
In order to meet the requirements that streaming data be stored and read in real-time on one hand, and that the storage medium be not too much internally fragmented on the other hand, WO 02/33586 A2 discloses a single file system featuring a first type of storage unit for storing audio and/or video streams and a second type of storage unit for storing non-stream data, wherein the size of the first storage unit is a predetermined multiple of the size of the second storage unit and second storage units exclusively occur in groups the same size as first storage units. For managing such file system, first to third data structures, first to third indicators, and first to fourth file information structures are used, indicating for the units, among others, whether they are free or not and/or whether they are subdivided or not. This prior art can be seen to have the disadvantage of a high complexity and computing power necessary to implement and execute effective maintenance algorithms for each of the numerous data structures.
A similar scheme has been disclosed in US 2006/0008257 A1. In this system, too, the data type is predetermined. Small files are stored using predetermined units of constant size also named clusters, and video data and large files are stored by using so-called superclusters which are the size of four regular clusters. A first file allocation table is provided for the small files, and a second file allocation table is defined for the large files. The second file allocation table is provided only dynamically upon writing. During interruptions in writing and at the end of the writing, the second file allocation table is converted and transferred to the first file allocation table. The first file allocation table is rather long and difficult to handle. The second file allocation table is more compact than the first allocation table, since there are far fewer superclusters than clusters. However, this advantage is lost at the end of the procedure because the second file allocation table is not maintained.